Database: WAL, batched clears of deletion records, and giving free space back - #53

Putting Project Zomboid back after its folder was emptied spent most of
an hour in the database, the save untouched meanwhile: every file's
deletion record was cleared with a statement of its own, a quarter of a
million of them, and with SQLite's default rollback journal every one of
them created, flushed and deleted a journal file.

- Deletion records are cleared in one transaction per save location, on
  putting a save back and when files come back in a snapshot
  (ClearDeletedFiles): 50,000 take a third of a second.
- The database runs in WAL mode with synchronous NORMAL: writes are
  appended to one log instead of each making a journal file of its own.
  The database stays whole whatever happens; a power cut can cost only the
  last moments' writes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

One statement per path, even inside one transaction, took 10s for 50,000
records under the race detector on CI's runners, and the test's limit
failed. 500 paths to a statement: 50,000 records in about 0.3s here. The
test's limit is generous now (30s): what it guards against took minutes.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

Asked in review: VACUUM inside store.Open made the first start after
updating as long as rewriting the whole database, and it needs about the
database's size free on its disk.

- store.Open no longer rewrites anything. A new database gets incremental
  auto-vacuum for free: openDB asks for it first in the connection string,
  while the file is still empty.
- A database from an older build is switched over by
  Store.EnableIncrementalVacuum, which the daemon runs once, two minutes
  after it has started, then hands free pages back as before (and hourly).
  It is not attempted without the database's size free next to it; the log
  says so, and it is tried again at the next start.
- The log says when the one-time rewrite ran and how long it took.

Test: a database created without auto-vacuum is left as it is by Open,
switched over by EnableIncrementalVacuum, and not rewritten a second time.
It fails on the previous commit, where Open did the VACUUM.

Co-Authored-By: Claude Opus 5.5 <[email protected]>